home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 5 / QRZ Ham Radio Callsign Database - Volume 5.iso / digests / tcp / 940103.txt < prev    next >
Encoding:
Internet Message Format  |  1994-11-13  |  5.8 KB
  1. Date: Sun, 29 May 94 04:30:03 PDT
  2. From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
  3. Errors-To: TCP-Group-Errors@UCSD.Edu
  4. Reply-To: TCP-Group@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: TCP-Group Digest V94 #103
  7. To: tcp-group-digest
  8.  
  9.  
  10. TCP-Group Digest            Sun, 29 May 94       Volume 94 : Issue  103
  11.  
  12. Today's Topics:
  13.                  More RSPF Help needed..... (2 msgs)
  14.  
  15. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  16. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  17. Problems you can't solve otherwise to brian@ucsd.edu.
  18.  
  19. Archives of past issues of the TCP-Group Digest are available
  20. (by FTP only) from UCSD.Edu in directory "mailarchives".
  21.  
  22. We trust that readers are intelligent enough to realize that all text
  23. herein consists of personal comments and does not represent the official
  24. policies or positions of any party.  Your mileage may vary.  So there.
  25. ----------------------------------------------------------------------
  26.  
  27. Date: Sat, 28 May 94 04:56:05 CST
  28. From: Jack Snodgrass                    <kf5mg@kf5mg.ampr.org>
  29. Subject: More RSPF Help needed.....
  30. To: tcp-group mailling list             <tcp-group@UCSD.EDU>
  31.  
  32.     We've been tearing out my hair trying to figure out how to link 2 RSPF 
  33. routers that use an IP Router to communicate.  It seems like RSPF should 
  34. work and NOT require that every station in the network Run RSPF, but we 
  35. just can't figure out how to make it work.  
  36.     
  37.     We've got:
  38.  
  39.     --------            --------            --------
  40.      kf5mg   <---440---> wb5tey <---144--->   k5rw
  41.     --------            --------            --------
  42.  
  43.     kf5mg and k5rw are running RSPF. When either one sends out it's RSPF 
  44. broadcast, the other station can't hear it because they're on separate
  45. networks. Is there an easy way to fix this?
  46.  
  47.     We've set up and AXIP link between the two RSPF routers and set up the 
  48. routes between k5rw and kf5mg to use wb5tey.  Now they can hear each others 
  49. RSPF broadcast, but the RSPF added routes are screwed up.  All of k5rw's 
  50. RSPF added routes on kf5mg show that they route through k5rw on 440 instead
  51. of wb5tey.  All of kf5mg's RSPF added routes on k5rw show that they route
  52. through kf5mg on 144 instead of wb5tey.  I'm guessing that the reason the 
  53. routes are screwed up is that RSPF assumes that since it can 'hear' the
  54. station direct ( because of the axip link ) the RSPF added routes assume 
  55. that they go direct to the remote system and don't take into account any
  56. pre-existing routes set up between the two RSPF routers.
  57.  
  58.     Next, we set up an ENCAP link in hopes that if the AXIP link was run 
  59. over the ENCAP link the RSPF added links would use the ENCAP link routes. 
  60. That didn't work either. The AXIP stuff goes over the ENCAP route, but
  61. the RSPF added routes still ignore the IP router that's in between the two
  62. RSPF routers.
  63.     
  64.     Someone is probably going to suggest that wb5tey ( in our example ) run
  65. RSPF. Yes... that will work, but I want/need to figure out this problem. 
  66. Once we get this working, we'll add RSPF to both of our Internet Gateways. 
  67. There's no way to get the network routers between the two gateways to run 
  68. RSPF.
  69.  
  70.     Anyway.... either there is something basic that I'm missing or RSPF is 
  71. really un-usable in a standard network and I can't see how one can really
  72. be using it. Any info/help/suggestions ( preferably working ) would be 
  73. appreciated. Thanks.
  74.  
  75. 73's  de  Jack  -  kf5mg
  76. Internet        -  kf5mg@kf5mg.ampr.org            -  44.28.0.14
  77. AX25net         -  kf5mg@kf5mg.#dfw.tx.usa.noam    -  home (817) 488-4386
  78. Dialup          -  kf5mg@tcet.unt.edu              -  work (looking  for)
  79. ===============================================================================
  80. ===           Buffalo's new area code.... 044.... "Deal with it"            ===
  81. ===============================================================================
  82.  
  83. ------------------------------
  84.  
  85. Date: Sat, 28 May 1994 16:28:01 -0400
  86. From: goldstein@carafe.tay2.dec.com
  87. Subject: More RSPF Help needed.....
  88. To: tcp-group@ucsd.edu
  89.  
  90. Jack,
  91.     
  92. >    We've got:
  93. >
  94. >    --------            --------            --------
  95. >     kf5mg   <---440---> wb5tey <---144--->   k5rw
  96. >    --------            --------            --------
  97. >
  98. >    kf5mg and k5rw are running RSPF. When either one sends out it's RSPF 
  99. >broadcast, the other station can't hear it because they're on separate
  100. >networks. Is there an easy way to fix this?
  101.  
  102. Not an easy way... 
  103.  
  104. This would have been solved fairly easily had RSPF2.2 been implemented.
  105. RSPF2.2 is a spec that makes clear that "normal" IP rules of "subnets"
  106. do NOT apply, and therefore you can create adjacencies using any kind
  107. of lower-layer (subnetwork in the OSIRM sense) connection and RSPF will
  108. use them if appropriate.  But the code in NOS does not override IP's
  109. routing function, and treats RSPF node groups as IP subnets, which 
  110. they ain't.  I don't know what hackery has been done recently to allow
  111. faking things, but it's all half-way.
  112.  
  113. Note that RSPF was designed to run on routers, but not be needed on
  114. end stations.  Your example is of course the opposite, and tries to
  115. use intellgent end systems to get past a lack of intelligent routers.
  116. Perfectly sensible but since I don't personally _use_ any of the RSPF
  117. variants currently implemented, I can't tell you what works.
  118.  
  119. If somebody would take the 2.2 spec and really implement it... Naaah,
  120. we're hams.  Why do it right when a quick and dirty early hack is 
  121. available?  Why should routing be different from the "202" modems?  :-(
  122.  
  123. (sig)>           Buffalo's new area code.... 044.... "Deal with it"            
  124. I must be missing something...
  125.     fred k1io
  126.  
  127. ------------------------------
  128.  
  129. Date: Sat, 28 May 94 11:21:03 CST
  130. From: fchavarr@udgserv.cencar.udg.mx (Fco. J. Chavarria -POLITEC)
  131. To: tcp-group@UCSD.EDU
  132.  
  133. unsub fchavarr@udgserv.cencar.udg.mx
  134.  
  135. ------------------------------
  136.  
  137. End of TCP-Group Digest V94 #103
  138. ******************************
  139.